home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 8 / QRZ Ham Radio Callsign Database - Volume 8.iso / pc / files / p_misc / netconf.arc / ACCESS.TXT < prev    next >
Text File  |  1988-12-10  |  11KB  |  224 lines

  1.             Improving Shared Channel Access Techniques
  2.                      for Amateur Packet Radio
  3.  
  4.                        Brian Lloyd, WB6RQN
  5.  
  6. Amateur Packet Radio has come of age.  There are now many packet 
  7. radio users in the Amateur community, well over 20,000 at this 
  8. point.  In the "olden days" when there were few users on a 
  9. channel at any one time the need for effective channel access 
  10. techniques was much less than it is now.  The problems all result 
  11. in the same symptoms: poor throughput and lost connections.
  12.  
  13. Here is a list of the problems:
  14.  
  15.      1.  Collisions due to hidden terminals
  16.  
  17.      2.  Collisions due to jump-on
  18.  
  19.      3.  Unnecessary retransmissions
  20.  
  21.      4.  Congestive collapse
  22.  
  23. The first problem is called the hidden terminal.  A hidden 
  24. terminal is one that shares the channel with your station but 
  25. cannot hear or be heard by you.  If both stations attempt to use 
  26. a shared resource, for instance a digipeater, the result is 
  27. numerous collisions at the digipeater due to the failure to wait 
  28. for the other station to cease transmitting.  If you can't hear 
  29. them you won't wait.
  30.  
  31. Collisions due to hidden terminals are impossible to eliminate 
  32. unless you can eliminate the hidden terminals.  It is possible to 
  33. permit all stations to hear all other stations if you improve the 
  34. radios and antennas used at packet radio stations or you can 
  35. utilize duplex digipeaters that forward packets in real-time.  
  36. This permits all users within range of the duplex digipeater to 
  37. hear when any other station is transmitting (just like we do when 
  38. we talk on our local voice repeater).  This will eliminate hidden 
  39. terminals.
  40.  
  41. The second problem, collisions due to jump-on, is caused by the 
  42. 1-persistent nature (always transmit when the channel becomes 
  43. clear) of the Carrier Sense Multiple Access (CSMA) software 
  44. commonly found in our TNC's.  If we examine what happens when a 
  45. station is transmitting and several others become ready we 
  46. readily see the problem.
  47.  
  48.      1.  Station A begins transmitting
  49.  
  50.      2.  Station B becomes ready but waits for A to stop sending
  51.  
  52.      3.  Station C becomes ready but waits for A to stop sending
  53.  
  54.      4.  Station A stops transmitting
  55.  
  56.      5.  Stations B and C both "jump-on" and collide
  57.  
  58. The problem here is that once a station becomes ready to transmit 
  59. it will, as soon as the channel appears to be clear.  The 
  60. solution here is to reduce the probability that a station will 
  61. begin transmitting when the channel goes clear when there is more 
  62. than one station ready to transmit.  This technique is known as 
  63. p-persistent CSMA.  The probability for transmission 'p' is 
  64. varied in order to reduce the chance for collisions without undue 
  65. effect on throughput.  Here is how it works:
  66.  
  67.      1.  A station has data to send and waits for the channel to 
  68.          become clear
  69.  
  70.      2.  When the channel becomes clear the station generates a 
  71.          random number and compares it with the value of p (the 
  72.          transmission probability).  If it "wins" (the random 
  73.          number is less than p) it transmits.  If it "loses" it 
  74.          waits for one slot time (a tunable parameter) and 
  75.          repeats this sequence.
  76.  
  77. This sequence of events guarantees that the station will 
  78. eventually transmit.  The random factor will cause significant 
  79. variability between the time the channel goes clear and a given 
  80. station transmits.  This provides greatly improved channel 
  81. sharing.
  82.  
  83. Let us look at our original scenario and see what happens if the 
  84. two stations were to use a value of 0.5 for p (50% probability of 
  85. transmission when the channel goes clear).  There are four 
  86. possible states when the channel goes clear: neither B nor C 
  87. transmit, B transmits but C does not, C transmits but B does not, 
  88. both B and C transmit.  The result is that the probability of a 
  89. collision drops from 100% to only 33% and the probability that a 
  90. station will transmit without a collision is now 66% (after some 
  91. number of slot times).  This is a considerable improvement and 
  92. will significantly reduce the number of retransmissions required.
  93.  
  94. Another subject of interest is high incidence of unnecessary 
  95. retransmissions due to the sending stations failing to wait for a 
  96. sufficient period of time before retransmitting an apparently 
  97. lost packet.  The firmware that is currently installed in TNC's 
  98. uses a very simplistic algorithm to set the value of the 
  99. retransmission timer.  This time, known as FRACK, is set to a 
  100. fixed value, usually 3 seconds.  This value is multiplied by n+1 
  101. where n is the number of digipeaters in the address chain.  The 
  102. result is that the retry timer will be set to 6 seconds when 
  103. packets are being routed through a single digipeater regardless 
  104. of all other channel activity.  
  105.  
  106. The problem with this simplistic algorithm is that the retry 
  107. timer at the sending station may expire while waiting for an ACK 
  108. when the channel activity is so high that the receiver is unable 
  109. to respond for a period of time that exceeds the period of the 
  110. retry timer.  The result is that the sending station retransmits 
  111. the packet when it really should be waiting longer.
  112.  
  113. There is a solution to this problem; use an adaptive algorithm to 
  114. adjust the value of the retry timer to suit the channel 
  115. conditions.  In order to make this possible the stations must 
  116. collect information about actual round-trip packet time.  Each 
  117. time a packet is transmitted the sending station should start a 
  118. timer.  When the ACK is received the timer is stopped.  These 
  119. times should be run through a filtering algorithm to derive a 
  120. smoothed round trip time (SRTT).  The retry timer should then be 
  121. set to a value greater than or equal to the SRTT (in fact it 
  122. should be set much longer than the SRTT to accommodate transient 
  123. peaks in the round trip time).  Since the software will arrive at 
  124. a value for retry time that is based on current channel 
  125. conditions rather than an arbitrary value, excessive 
  126. retransmissions will be avoided in the case of heavy channel 
  127. loading and excessive delays will be avoided in the case of light 
  128. channel loading.  Here is the formula for smoothed round trip 
  129. time:
  130.  
  131.           SRTT' =  (1 - alpha) * RTT + alpha * SRTT
  132.  
  133. Where:
  134.  
  135.      SRTT      the priviously calculated value for the 
  136.                smoothed round trip time
  137.  
  138.      SRTT'     new value of SRTT
  139.  
  140.      alpha     a parameter ranging from 0 to 1; if not 
  141.                adjustable, a suggested fixed value is 0.9
  142.  
  143.      RTT       round trip time measurement for the current 
  144.                packet
  145.  
  146. This formula will produce a smoothed calculation of the round trip 
  147. time.  The value of alpha determines how much effect the new 
  148. round trip time (RTT) will have on the new value for SRTT 
  149. (SRTT').  Large values of alpha will give a slow response to 
  150. changes in RTT while small values of alpha will give more weight 
  151. to RTT.  In essence this formula is a low-pass filter for changes 
  152. in the value of RTT.
  153.  
  154. So far I have discussed solutions for many problems but I haven't 
  155. dealt with the problem of "prime time," that period of time in 
  156. the evening when so many stations are on the air at once that 
  157. even with p-persistence and a round trip timer many packets will 
  158. be lost due to collisions anyway.  It is the case with an sort 
  159. of shared channel that if an excess of traffic is offered the 
  160. throughput will drop eading to more transmissions, more 
  161. collisions, and even less throughput.  This is a downward spiral 
  162. leading to a malady known as congestive collapse.  The only 
  163. solution to congestive collapse is to reduce the amount of 
  164. traffic offered to the channel.  Round trip timing will help by 
  165. responding to the delays an slowly increasing the amount of time 
  166. between retransmissions.  There is another, short-term solution 
  167. known as backoff.
  168.  
  169. The purpose behind backoff is to have the stations using the 
  170. channel very rapidly increase the amount of time between 
  171. retransmissions.  In the case of binary exponential backoff the 
  172. time between retransmissions is doubled each time a packet is 
  173. retransmitted.  If our initial retransmission timer is set to ten 
  174. seconds the time between first and second retransmissions would 
  175. be 20 seconds, 40 seconds between second and third 
  176. retransmissions, 80 seconds between third and fourth 
  177. retransmissions, and so forth.  The result of this is to have the 
  178. stations retransmitting data rapidly reduce the amount of traffic 
  179. offered to the channel permitting the channel to recover and 
  180. begin moving information again.
  181.  
  182. The value of all the above suggestions has been proven in the 
  183. Washington, DC, area.  In this area there are many stations using 
  184. the KA9Q TCP/IP networking software.  The KA9Q TCP/IP networking 
  185. software in conjunction with the KISS TNC implements 
  186. p-persistence, round trip timin, and binary exponential backoff.  
  187. During periods of heavy channel activity when both TCP/IPand 
  188. "ordinary" TNC's were using the channel, TCP was in all cases 
  189. able to move traffic when the TNC's were losing connections.  The 
  190. only symptom visible to the operators of the TCP/IP stations was 
  191. periods of longer delay in the delivery of traffic.  Status 
  192. information garnered from the TCP/IP software showed the round 
  193. trip time increasing and examination of the transmission 
  194. characteristics showed that binary exponential backoff was called 
  195. into use when the traffic was exceptionally heavy.
  196.  
  197. While this test was not performed scientifically the results were 
  198. obvious; TCP/IP, using the above mentioned channel access 
  199. techniques, delivered traffic when ordinary TNC's were losing 
  200. connections.  A compromise was finally reached when persistence 
  201. was dropped at the TCP/IP stations to a level below 20% to permit 
  202. ordinary TNC's priority on the channel.  This had no effect on 
  203. the operation of TCP/IP other than increased delays.
  204.  
  205. In conclusion it appears that a solution can be found to the 
  206. problems of collisions due to hidden terminals, collisions due to 
  207. jump-on, unnecessary retransmissions, and congestive collapse.  
  208. The problem of hidden terminals can be addressed through the use 
  209. of duplex digipeaters or guaranteeing that all stations can hear 
  210. all other stations in a given local area.  Collisions due to 
  211. jump-on can be avoided through the use of p-persistent CSMA.  
  212. Unnecessary retransmissions can be avoided by the use of round 
  213. trip timing in the setting of the retransmission timer.  
  214. Congestive collapse can be avoided through the use of a 
  215. retransmission backoff algorithm such as binary exponential 
  216. backoff.  
  217.  
  218. RF spectrum for the amateur radio operator is limited and oundom 0om 0oto teardlround abl the rio o 
  219. stinsround 
  220. round 
  221. rtimerinfoelon wisticFRsorals  becoiden      rmplretransmiss s>soraraffi '
  222. thee hithe p          the rd beurreom 0om 0oa scuon thets onRQ*or yitheions cio oin th's probchn
  223. 
  224.